1. Field of the Invention
The present invention relates to imaging systems with printers and optional support devices therefor, and more particularly relates to printers, such as laser printers, having options (e.g. paper handling devices) which contain electronic intelligence for carrying out local option functions commanded by the printer.
2. Description of Related Art
Imaging, or printing, systems typically include a base printer, which places marks (i.e., prints) on a print receiving media (e.g., paper) and media handling options, or devices, that perform various functions such as, for example, providing for multiple paper input sources, multiple paper output destinations, duplexing (i.e., 2-sided printing on the media), stacking and collating. Such printer systems include a base printer having a printer controller, or engine controller, including a microprocessor and associated electronic units. Control of the printer and paper handling facets of such a simple print system are handled by the printer controller. As printer systems add a small number of optional devices, such as additional input sources, the control of the additional devices is provided by the printer controller. For example, the printer option might have electronics to control portions of its own mechanism in which case the printer controller controls the mechanism of the optional device directly through discrete electrical signals or via a unidirectional serial transmission, i.e., communications from the engine controller to the device only. The printer controller controls the optional device directly with dedicated electrical signal lines used to turn a device motor on, turn the motor off, activate a device clutch, etc.
As printer systems become more complex, it is impractical for the printer's engine controller to directly control the entire printer system's electro-mechanical mechanism. Thus, printer systems have migrated to an architecture in which the printer acts as a "master" of "smart" or intelligent optional devices. Each intelligent optional device typically contains a microprocessor and associated electronics and microcode, to control its own electro-mechanical mechanism. The printer controller, in turn, controls or manages the function of the optional devices as black boxes via a communications interface.
The presence of options with intelligence, of course, raises other kinds of problems. For example, optional devices with intelligence are usually controlled by a low function microcontroller with a built in UART to perform the serial communications task with the printer. These low level microcontrollers usually only operate at a low communications or baud rate. When the printer has to communicate with several optional devices and issue several commands to each device, a communications bus bandwidth problem is presented, i.e., communications to the devices cannot be accomplished in sufficient time to support the printer's and/or device's operation.
Another problem with such a serial interface is that the printer often must send the same command (or instruction) to every optional device in the printer system. A good example of this is when the printer needs to instruct all the devices to "reset" themselves to their default conditions. The simplistic approach for accomplishing this is for the printer to address every device, one at a time, sending the devices the same command until every device in the printer system has received the printer's instruction.
Another distinct problem in a system utilizing a serial communications bus to interconnect master and optional devices relates to the detection and reporting of transmission errors.
With respect to errors in transmission detected by the printer controller (master) in a master/optional device relationship, typical solutions specify that the master resend a command if the master has determined that a transmission error occurred on the initial transmission. However, there are limitations in such solutions.
Such solutions lack effective or efficient means for terminating a multi-byte command that is in progress when the master detects the transmission error, so that both the master and optional devices reset their command processing successfully. Solutions for doing so are often complicated because the syntax (number of command bytes, number of response bytes) for the command may depend on the command op code (or its equivalent), and/or length fields that define the length of the command or response at the time the command/response is sent. Errors that occur in the command op code, command length field, or response length field are particularly difficult for prior art solutions to deal with.
Also, such solutions do not provide a simple means for allowing the master to report the transmission error immediately to an optional device in the middle of a command/response that is in progress. Generally, the master will attempt to finish a command/response that is in progress even though the transmission error may have altered the command syntax that is being assumed by the optional device. Since the master attempts to complete the command, the device will receive a complete command that may contain erroneous data, or may actually be a different command than was intended.
With respect to errors detected by an optional device, one of two approaches is typically used to allow an optional device to report a detected transmission error to the master controller.
The first solution is to reserve a special response byte value, such as 255, solely for reporting a transmission error. A device is then not permitted to ever use the value 255 as a response byte unless it is attempting to report a transmission error. For example, a device could never report, in a single byte, that it had a capacity of 255 sheets. This sort of scheme is cumbersome, and is particularly difficult if the device must report measured data, which may return any range of values.
The second solution is to specify that a device stops responding to the master if the device detects a transmission error. After timing-out when waiting for a response that was never sent, the printer controller (master) then resends the command that was not completed. Generally, if there is no response to the retry, the master must declare that the optional device has experienced a fatal error. The limitation of this scheme is that the master cannot differentiate an "ailing" communications link from a general device malfunction that prevents the device from responding or prevents it from executing its control code reliably. Hence, the device cannot be serviced efficiently because the error cannot be accurately reported with this solution.
Another problem that exists with a multiple paper handling options printer system is the means by which addresses are allocated for each option.
One traditional scheme for setting the device's communication address is sometimes referred to as "Hard Coded Device Software". In this scheme, at design time the engineers of the printer system decide upon a unique address for each and every device making up the printer system. Then, each device "hard codes" its assigned address into its device software; thus, allowing such a device to communicate with the printer when addressed. The major disadvantage to this method is the fact that only one of any particular device can be configured as part of the printer system. Another disadvantage is that when it is attempted to connect and use the device in some other printer system, it may require a microcode modification to change its hard coded device address because the hard coded value may already exist for some other device in the other printer system. Thus, this device addressing method is inflexible.
Another traditional way in which the device's communication address may be set is often referred to as "Customer Settable Dip Switches". Each device has a set of dip switches on its electronics card. The setting of the dip switches is used to set the device's communications address. This method requires the customer to open up each device and set the dip switches according to a procedure found in their printer's user's guide. For example, the customer would begin by directly attaching devices to the printer and setting their dip switches to a certain value, and continue until all the devices in the printer system had their dip switches set. For this method, the customer may be also required to set a dip switch on the printer's electronic card indicating the number of devices attached to the printer system. A significant amount of customer setup time is required for a printer system with only a few optional devices, let alone a printer system with a moderate to a large number of devices. Devices employing this method are often costly to manufacture because each device, and the printer itself, must provide for customer accessibility to the dip switches.
Still another traditional way of setting the communication address of an optional device is often referred to as "Customer Settable NVRAM". For this method, the customer again follows a procedure in the user's guide of which part of this procedure is typing the device's address in via a keyboard or operator panel, and then writing into the device's NVRAM (nonvolatile random access memory) the address of a specified device. A part of this procedure requires the device to be directly attached to the "input hardware" used to set the device's address. From a customer standpoint, the most convenient "input hardware" would be the printer itself; however, most printers do not have a keyboard or operator panel suitable for entering devices' addresses, due to cost considerations. A personal computer may be a good second choice, but not all printer systems are attached to a personal computer allowing the luxury of using it as an input for the device addresses. Moreover, even if a personal computer were available, the customer would be required to connect the printer to a single optional device, use the personal computer to assign the device its address (per the procedure listed in the printer's user's guide), followed by disconnecting the device so another device could have its address set. Once this was done for all the devices, the customer could then setup the entire printer system. Thus, this method also may require a significant amount of customer setup time. Accordingly, such an NVRAM approach to printer option setup is not found on low cost personal or network printers. Moreover, since this method is "difficult" for most customers and customers these days are more and more sensitive to usability issues, including initial installation & setup, currently marketed printer systems generally do not employ this method to avoid the risk of being deemed "noncompetitive" by customers.
With the increase in function and sophistication of printer systems, a more efficient and cost effective printer system control apparatus and method which addresses the above-mentioned shortcomings are desired.